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Abstract 

We describe motivation, design, use, and implemen¬ 
tation of higher-order abstract syntax as a central rep¬ 
resentation for programs, formulas, rules, and other 
syntactic objects in program manipulation and other 
formal systems where matching and substitution or 
unification are central operations. Higher-order ab¬ 
stract syntax incorporates name binding information 
in a uniform and language generic way. Thus it acts 
as a powerful link integrating diverse tools in such 
formal environments. We have implemented higher- 
order abstract syntax, a supporting matching and 
unification algorithm, and some clients in Common 
Lisp in the framework of the Ergo project at Carnegie 
Mellon University. 

1 Introduction 

Higher-order abstract syntax is a generalization of the 
usual data type of abstract syntax tree that is used to 
represent syntactic objects in implementations of sys¬ 
tems that manipulate programs, formulas, rules, etc. 


*This research was supported in part by the Office of Naval 
Research under contract N00014-84-K-0415 and in part by the 
Defense Advanced Research Projects Agency (DOD), ARPA 
Order No. 5404, monitored by the Office of Naval Research 
under the same contract. 

tThe authors can be reached via electronic mail on the 
ArpaNet as fp@cs.cmu.edu and conalfics.cmu.edu. 


Higher-order abstract syntax uses a simply typed A- 
calculus enriched with products and polymorphism 
and thus extends a proposal by Huet and Lang [11], 
It differs from LF [1,9] in that we do not allow depen¬ 
dent function types, since no appropriate matching 
or unification algorithm is known. Moreover, we feel 
that products and polymorphism, which are absent 
from LF, are an essential feature for practical appli¬ 
cations. 

The requirements that led to the design of higher- 
order abstract syntax arose through one of the Ergo 
project’s goals, namely to build a language-generic 
environment for formal program development. Com¬ 
ponents of such an environment that we have com¬ 
pleted include a parser and unparser generator, an 
attribute grammar compiler, a type inference facility, 
and an interaction facility based on the X window 
system. Other components now being implemented 
include a language- and rule-independent transforma¬ 
tion system and a logic-independent deduction sys¬ 
tem. 

Such a program design environment should support 
rapid prototyping of all relevant aspects of program¬ 
ming languages. That is, one should be able to easily 
specify syntax, semantics, and transformation rules 
for a language and obtain an environment tailored to 
manipulating programs in that language. Our goals 
are even broader, since we believe that logical lan¬ 
guages and proof systems are essential for formal pro¬ 
gram development and, therefore, that we must be 
able to support these as well. 

The requirements for the internal representation of 
syntactic objects in such a system are quite different 
from the requirements in a single-language system. 
On the other hand, many of the same issues come up 
in compiler generation systems. We believe the basic 
principles that should guide the design of an inter¬ 
nal representation for programs (and other syntactic 
objects) in our context are: 




• Simple, user-friendly syntactic and semantic defi¬ 
nition of a language should be supported through 
the representation. It should also allow definition 
of transformation and inference rules in a simi¬ 
lar style. In particular, it should be possible to 
avoid complex side-conditions wherever possible. 

• Efficient and correct use can be made of the def¬ 
initions. In particular, the system must be able 
to efficiently and correctly transform programs 
or apply inference rules. 

• The representation should be general enough to 
be used by all relevant tools in an environment, 
thereby providing for a high degree of integration 
between the tools. 

Abstract syntax trees have proved very useful in 
similar contexts. This has been well established in 
systems like PSG [2], the Cornell Synthesizer Gen¬ 
erator [19], Gandalf [8,6], or Popart [20]. However, 
abstract syntax trees do not completely satisfy the 
more general requirements listed above. The crux of 
the problem is that almost all languages in this con¬ 
text will have name binding constructs. These bind¬ 
ing constructs make correct matching and substitu¬ 
tion difficult (see Section 2 for some examples). Also, 
the requirements of a language generic system do not 
allow incorporation of the information about binding 
constructs the way it can be done in single-language 
systems. Instead, the language implementor must ex¬ 
plicitly define the binding constructs of the language 
once and for all, and the system must be able to in¬ 
corporate this information into the representation. 

We found that all static binding constructs we 
examined can be represented in a simply typed A- 
calculus with Cartesian products. We also added 
polymorphism to the representation to make it pow¬ 
erful to enough to conveniently state general transfor¬ 
mation and inference rules. A somewhat less general, 
but closely related representation was first proposed 
by Huet and Lang [11]. It should be noted that our 
representation in no way prohibits dynamic extent of 
variables, nor does it mean a commitment to a call- 
by-name over call-by-value semantics. Also, since the 
types are syntactic sorts, no commitment to the se¬ 
mantic type structure of the object language is made. 
Higher-order abstract syntax is appropriate and use¬ 
ful for almost all languages, including Prolog, ML, 
Pascal, various logics and type theories, Hoare logics, 
etc. 

Adopting this typed A-calculus representation al¬ 
lows us to use the very powerful mechanism of higher- 
order unification (of which higher-order matching 


and substitution are special cases). We have imple¬ 
mented Huet’s algorithm [10] for higher-order uni¬ 
fication with extensions to deal with products and 
polymorphism. It is complete except for some rare 
cases involving higher-order polymorphism. In cer¬ 
tain cases, straightforward matching would produce 
too many unifiers to be useful, and in this case the 
client (user or program) can preinstantiate some vari¬ 
ables to generate a more specialized version of a pat¬ 
tern. Note that this problem of too many rewrites is 
inherent in program transformation, and not a defect 
of our implementation. On the contrary: our imple¬ 
mentation provides a simple way of stating a very 
general, valid rule and then partially instantiating it 
to a more specialized one which is automatically cor¬ 
rect and can be applied efficiently. 

We also provide a first-order interface to higher- 
order abstract syntax. This first-order interface is 
defined through the augments in the grammar and is 
used by tools that still depend on the conventional no¬ 
tion of abstract syntax (like the parser and unparser 
generators and the current attribute grammar com¬ 
piler). As discussed in Section ?? the efficiency loss 
due to the dual interface seems to be minimal. 

In the remainder of this paper, we first point out 
some of the inadequacies of the representation of pro¬ 
grams as abstract syntax trees. We then discuss 
higher-order abstract syntax and illustrate its use 
through a diverse set of examples. Finally, some im¬ 
plementation issues concerning higher-order abstract 
syntax and related work are discussed. 


2 Some Motivating Examples 

In this section we highlight some of the problems that 
arise in matching and substitution due to the presence 
of binding constructs in a language. Almost all lan¬ 
guages have these binding constructs, though some¬ 
times they are not immediately apparent. For ex¬ 
ample, in Prolog the “free” variables in a clause are 
actually bound in that clause, since they are clearly 
distinct from variables with the same name in other 
clauses. A function definition stated as f(x) = b actu¬ 
ally binds x and / (see the beginning of Section 3.2). 

The rules we present throughout this paper are 
stated without any semantic side conditions such as 
strictness or termination. Depending on the language 
semantics, such conditions may still be necessary to 
ensure full semantic equivalence between the trans¬ 
formed programs. However, it should be noted that 
in all the examples the syntactic side conditions on 




the rules disappear without compromising the valid¬ 
ity of the rule. 

2.1 Correct Matching and Substitution 

This problem should be very familiar; it is generally 
called “variable capturing”. It appears in two differ¬ 
ent forms: during matching and during substitution. 
Consider the rule of let-conversion. 

let x = e in b <*=>■ b[e/x] 

Here are two incorrect applications of this rule. 
Note that reading them from right to left shows the 
problem of doing correct matching against b[e/x}. 

let x = y in let y = 5 in x * y 
let y = 5 in y * y 
let x = 5 in let x = x * x in x 
let x = 5 * 5 in 5 

What is required for correct substitution is recog¬ 
nition of name conflicts and renaming of bound vari¬ 
ables. If this rule is read from right-to-left, it is 
clear that there are many possible ways of abstract¬ 
ing an expression from a program, and that there¬ 
fore straightforward matching on any representation 
would be very non-deterministic. In a situation like 
this the solution is to partially instantiate the pattern 
before matching. 

2.2 Variable Occurrence Restriction 

Variable occurrence restrictions again require renam¬ 
ing of bound variables during substitution, or failure 
of matching. The following example is taken from a 
formalization of a natural deduction system to show 
the variety of circumstances in which these problems 
occur. 


-VI, where x not free in T. 

r b MxP 

If this rule is used by matching against the lower 
line, the restriction on x must be checked separately 
— it is difficult to formulate the rule simply and con¬ 
cisely. Ideally, x would be renamed to a new variable 
a: 0 if x is already free in T. If the rule is used in 
the other direction, it should simply not match if x 


appears in T. As we will see in Section 3.3, rules in¬ 
corporating occurrence conditions can be formulated 
easily and applied correctly using higher-order ab¬ 
stract syntax. 

Note that in a system that uses first-order abstract 
syntax, not only would the rule be conditional, but 
the language implementor would somehow have to 
define a predicate not-free-in for the language in 
question. 

2.3 Correct Treatment of Contexts 

Many program transformation rules can be stated 
naturally through the use of contexts. Correct appli¬ 
cations of these rules, however, is tricky. For example, 
a rule propagating computation into the branches of 
an if expression could be written as 

C [if p then a else b] <*=>• if p then C[a] else C[b] 

Consider the following incorrect application. 

let p = false in if p then 1 else 2 
if p then let p = false in 1 
else let p = false in 2 

As noted in [16] syntactic conditions on C are dif¬ 
ficult to formulate if one wishes to eliminate the pos¬ 
sibility of incorrect rule application as in the exam¬ 
ple. The use of higher-order abstract syntax solves 
this problem by allowing the statement of the rule 
as above, but automatically prohibiting the incorrect 
use below without any additional conditions. 

3 Design and Use of Higher-Order 
Abstract Syntax 

In this section we will sketch higher-order abstract 
syntax and illustrate how it solves the problems men¬ 
tioned in the previous section. 

3.1 Well-Sorted First-Order Abstract Syntax 

Ordinarily a parser creates untyped abstract syntax 
trees. They can be viewed as terms where the opera¬ 
tors in the language act as function symbols, and the 
lexical terminals as constants. Variables as such do 
not exist in this representation, that is, object lan¬ 
guage variables are represented as identifiers, which 



are all considered constants. In some systems in 
which program schemas are considered, explicit no¬ 
tations for schema-variables are introduced. These 
schema- or meta-variables become variables in the ab¬ 
stract syntax. 

In the context of syntax manipulation tools the 
need for types in the abstract syntax soon arises. This 
is because one needs to be able to test whether a sub¬ 
stitution of a subterm for another is syntactically le¬ 
gal. The types then are derived from the syntactic 
sorts or syntactic categories. The notion of syntactic 
sort and object language type usually do not coincide, 
though typically the object language types refine the 
syntactic sort structure. 

As an example throughout this paper we will use 
a simple functional language with mutually recursive 
function definitions, because it provides a good frame¬ 
work for illustrating the use of higher-order abstract 
syntax. 

We begin with a grammar that, except for special 
fonts, can be read directly by the parser and unparser 
generator in the Ergo Support System. The gram¬ 
mar augments surrounded by “< >” indicate the ab¬ 
stract syntax that the parser constructs to represent 
the concrete syntax on the left. We omit some of the 
straightforward grammar augments. 

P ::= rec D <rec °(D)> 

D ::= F = E \ D 0 and D\ 

F ::= V \V F 

E ::= V <var(E)> 

| C <const(E)> 

j if E 0 then E\ else E 2 <ite(E 0 , E\, E 2 )> 
| let B in E <let °{B,E)> 

| E 0 Ei <apply(E 0 ,Ei)> 

| lam V.E <lam °(V,E)> 

B ::= V = E\B 0 and B x 

This completes the outline of a view of abstract 
syntax as typed terms, where operators correspond to 
function symbols and syntactic sorts to types. Meta¬ 
variables or schema variables would have to be a dis¬ 
tinct syntactic category. 

In the Ergo Support System, the first-order ab¬ 
stract syntax as defined by means of the grammar 
above is used by the parser, unparser, formatter, 
and interaction facility (for highlighting proper sub¬ 
terms). However, if a higher-order view is defined 
for a language the abstract syntax tree is never built. 
Instead, we parse directly into higher-order abstract 
syntax. 


The first-order view from the higher-order repre¬ 
sentation is then created through a function that de¬ 
composes a term into its first-order operator and ar¬ 
guments. Currently, this function must be specified 
directly by the language implementor. 

3.2 Higher-Order Abstract Syntax 

Motivated by the examples in Section 2 we now gener¬ 
alize to higher-order terms. This representation was 
suggested by Huet and Lang [11] for use in program 
transformation. In this first generalization, simply 
typed lambda terms represent programs. Syntactic 
sorts become A-calculus types. The lexical termi¬ 
nals and the operators that do not introduce vari¬ 
able bindings are, respectively, first-order and second- 
order constants of the A-calculus. 

Another crucial change occurs for the variables. 
Operators in the object language that are binding 
constructs are now explicitly encoded as third-order 
constants. As the following examples will show, this 
requires that bound object language variables actu¬ 
ally become variables in the typed lambda calculus. 

The generalization to simply typed A-terms is still 
insufficient for many languages. The problem is the 
presence of lists of various forms: lists of arguments, 
lists of bound variables, lists of mutually recursive 
function definitions. The usual solution is to curry 
functions, which enables representation, but not sim¬ 
ple, finitary definition of transformation or inference 
rules. See, for example, the formalization of Hoare 
logic in LF [1], where the natural encoding remains 
restricted to a two-register machine. More generally, 
LF can naturally formalize an n-register machine for 
any fixed n, but only give a very unsatisfactory en¬ 
coding of full Hoare logic. 

To solve this problem, we have extended higher- 
order abstract syntax and the unification aigorithm to 
handle products. In our formulation of the A-calculus 
with products, we use pattern binders akin to ML, 
rather than constants fst and snd. The product is bi¬ 
nary and associates to the left. Our example language 
has three constructs that introduce scope: let, lam, 
and rec. Figure 1 shows how they are represented in 
higher-order abstract syntax. 

In order to express transformation rules through 
patterns, we now augment the grammar for the ob¬ 
ject language to a grammar for an associated pattern 
language. The pattern language is not universal, but 
rather is be constructed in harmony with a given ob¬ 
ject language. Because of the higher-order nature of 




let Vi = Ei and ... and V n = E n in E as 
lam V. E as 

rec Vi Vn ... V lni = El and ... and V m V ml ... V mrtm = E m as 
<rec(A(Vi,..., V m ) . <lam(AUn . lam(AUi 2 ... E 1 ...)),. 


<let(A(Vi.. .Vn) ■ E)(E 1 ,.. .,E n )> 
<lam(A V.E)> 

lam(AU m i . lam(AU m2 ...E m .. .))))> 


Figure 1: Representation of let, lam, and rec. 


our abstract syntax, this requires more than just the 
introduction of schema variables. Typically, an object 
language and its associated pattern language will dif¬ 
fer by three or four productions. These additional 
productions provide for specifying variable applica¬ 
tions, in some cases also for variables, abstractions, 
and products. 

Here we include higher-order application and ab¬ 
straction. Note how the augments of these produc¬ 
tions differ from the cases building apply and lam. 

E ::=... | E 0 [E!] <£ 0 (£i)> 

| XV. E <A V.E> 

Let us reconsider the let-conversion rule from Sec¬ 
tion 2.1. We can now state a single polymorphic rule 
for let-conversion. The first line shows how it would 
actually be stated, the second line shows the hidden 
type variable a. The given type is the most gen¬ 
eral, with let being a polymorphic constant of type 
(a —*■ E) —*■ a —*■ E. Remember that the types in 
the representation correspond roughly to the syntac¬ 
tic categories of the language definition. 

let x = e in b[x] <*=>■ b[e] 

let x a = e a in b a ^,E [x a ] •<=>■ f>[e] 

We can match this rule, for example, against the 
following term 

let x = 5 and y = 6 in x * y 

In this example, the substitution will be 

a <— E x E 

e < — (5,6) 

b <— A (x,y) .x*y 


b[e] = (\{x, y) .x*y) [(5,6)] = 5 * 6 


The Fold and Unfold rules [3] provide two more ex¬ 
amples of how rules can be concisely and easily for¬ 
mulated in this framework. Here we show the simpler 
Unfold rule and give a definition that states one sin¬ 
gle rule for any number of mutually recursive function 
definitions. 

rec / = b[f] [/] <S=^ rec / =b[b[f][f]] [/] 

We now consider an example where this rule is ap¬ 
plied to a recursive function definition. The objective 
of the transformation is to replace the first recursive 
call to gcd by the properly instantiated function body. 
This is achieved in two steps: the first is to replace 
a recursive function call by its definition, the second 
is to use lam-reduction (analogous to /3-reduction, 
but on the level of the object language) to obtain the 
instantiated body. 

rec gcd x y = if x = 1 then 1 

else if x = y then x 
else if x < y then gcd y x 
else gcd (x - y) y 

This program matches the unfold rule in four dif¬ 
ferent ways, each either unfolding or not unfolding 
each of the two recursive calls. In the substitution 
below, g abstracts the occurrences of gcd that are to 
be unfolded and / the ones that remain unchanged 
in the transformation. 

b <— Xg . Xh . if x = 1 then 1 

else if x = y then x 
else if x < y then g y x 
else h (x — y) y 


Then the right-hand side becomes 







Applying the substitution to rec / = 6 [6 [/][/]][/], 
the right-hand side of the rule, yields: 

rec gcd x y = if x = 1 then 1 

else if x = y then x 
else if x < y then 
(lam x . lam y . 
if x = 1 then 1 
else if x = y then x 
else if x < y then gcd y x 
else gcd (x - y) y) y x 
else gcd {x - y) y 

Now we can apply lam-reduction twice, yielding 
the correctly unfolded program: 

rec gcd x y = if x = 1 then 1 

else if x = y then x 
else if x < y then 
if y = 1 then 1 

else if y = x then y 
else if y < x then gcd x y 
else gcd (y — x) x 
else gcd {x - y) y 

Then, using two simple rules for simplifying 
if-then-else expressions we can eliminate some of 
conditions to get 

rec gcd x y = if x = 1 then 1 

else if x = y then x 
else if x < y then 
if y = 1 then 1 
else gcd (y — x) x 
else gcd {x - y) y 

Higher-order rule descriptions, like the description 
of Unfold, can be embedded in a programming lan¬ 
guage so that compositions of transformations like 
the one above can be described as short pieces of 
programs. A good example of such a system is 
AProlog [15]. Higher-order abstract syntax provides 
a way for systems like AProlog to use readable con¬ 
crete syntax for programs without sacrificing power, 
simplicity of expression, or efficiency. 

3.3 Propagating Contexts 

Here is the promised solution to the challenge in Sec¬ 
tion 2.3. The context variable C simply becomes a 
second-order variable and will be instantiated only to 
proper contexts. A typical rule would be the follow¬ 
ing: 


U[if p then a else 6] if p then C[a] else C\b] 

See Figure 2 for an example of a context prop¬ 
agation rule and its use with higher-order abstract 
syntax. The last counterexample demonstrates how 
higher-order matching ensures that bound variables 
will not leave their scope. This restriction is not en¬ 
forced through a test after a potential match is pro¬ 
duced, but is an integral part of the higher-order uni¬ 
fication algorithm. 


3.4 Raising Rules 

So far all examples have been second-order. However, 
there are many applications, in which one would like 
to use third-order matching. In the context of raised 
rules (as discussed here), our algorithm will always 
terminate (a result due to Miller [13]). Raised rules 
are a significant generalization of Huet & Lang’s tem¬ 
plate matching [11]. 

Here is an example of an equivalence we would to 
obtain as a consequence of a general rule for context 
propagation. 

let x = y * y in 
let z = x * y in 

if y > 0 then z else x 

if y > 0 

then let x = y * y in 

let z = x * y in z 
else let x = y * y in 

let z = x * y in x 

This does not match the context propagation rule 
from above, since a substitution like a < — z would be 
captured by the binding on A general solution in a 
case like this is to raise the order of the rule through 
explicit abstraction. This solution is inspired by Paul¬ 
son’s V-lifting [18] that was discovered independently 
by Miller and called raising [13]. Both raise the order 
of certain equations in the presence of parameters. 
Raising requires that we be able to explicitly men¬ 
tion the “A” of the A-calculus representation in the 
pattern. The following is a raised version of context 
propagation. 

C[Xx . if p then a[x] else 6[a:]] •$=>■ 
if p then C[\x . a [a;]] else C[\x . 6[a:]] 



C[if p then a else 6] <*=>■ if p then C[a) else C[b] 

x * (if x > 0 then 1 else —1) -*=>■ if x > 0 then x * 1 else x * (—1) 

where C <— Xz . x * z, a <— 1, b < -1, p <— x > 0. 

(if x > 0 then 1 else —1) * x <*=>• if x > 0 then l*x else (—1) * x 

where C <— A z . z*x, a <— 1, b < -1, p <— x > 0. 

let q = false in if q then 1 else —1 if q then let q = false in 1 else let q = false in — 1 

since C <— (A^.let q = false in z), a <— 1, b < -1 and p <— q leads to a clash. 

Figure 2: Examples of context propagation. 


This operation raised the order of a and b to be 
second-order variables, C is now a third-order vari¬ 
able of type (E E) E. A match of this pattern 
against its motivating example is given through the 
substitution 

C <— A / . let x = y *y in let z = x *y in f[(x, z)\ 

p <— y > 0 

a < — X{z 0 ,z\).z\ 

b <— X(z 0 ,z 1 ).z 0 

Again note the use of polymorphism in the rule 
description and the instantiation of type variables to 
product types to capture the fact that this should 
apply to any number of bound variables that may 
appear in the branches of the if, but not in the test 
V- 

This also shows that variable occurrence conditions 
become unnecessary. The fact that p could not de¬ 
pend on any variable bound in the context is implicit 
in the formulation of the rule. 

Our current incomplete support for polymorphism 
cannot handle this example. 

4 Other Applications 

Higher-order abstract syntax captures the binding in¬ 
formation present in a language. We have shown in 
Section 3 how this can be used for correct unification, 
matching, and substitution and direct formulation of 
rewrite rules in the context of a language-generic en¬ 
vironment for manipulating programs, formulas, and 
other syntactic objects. 

In the following subsections we indicate how other 
components of such a generic environment can exploit 


the scoping information embedded in the representa¬ 
tion. 


4.1 Type Inference 

In the Ergo Support System, we have prototyped 
a component for general type inference, given the 
semantic type signature of a language. Conceptu¬ 
ally, the type signature is translated into an attribute 
grammar that will do type inference on a given term, 
though the actual implementation is slightly more ef¬ 
ficient. 

An early problem with our type signature specifi¬ 
cation language was that implicit binding constructs 
could not be handled. For example, in Prolog the 
binding of the free variables over a clause is implicit, 
and it need not have the same type as a variable with 
the same name in another clause. Other languages, 
where binding constructs are complicated could not 
be handled either. An example is an imperative lan¬ 
guage where an arbitrary number of local variable 
declarations may follow a begin. 

With the use of higher-order abstract syntax these 
problems disappear, since the necessary analysis is 
done once and for all at parse time. Without go¬ 
ing into detail, here is a possible type signature for 
our functional example language that is based on the 
higher-order abstract syntax representation. Note 
that this completely eliminates the need for analyz¬ 
ing the syntactic categories D, F, and B, which are 
not present in the higher-order abstract syntax. Con¬ 
stants of the object language may be declared sepa¬ 
rately — the last line is an example. 

Briefly, the operator in the language (constant in 
the higher-order abstract syntax) is listed with their 



semantic types. Type constructors of the object lan¬ 
guage are funtype, prodtype, boolean, and number, type 
variables are a and 0. 

rec : (a —»• a) —»• a 

ite : boolean — > a — > a — > a 

let : {a —> 0) — > a —> 0 
apply : (funtype a 0)a0 
lam : («-»•/?)-»• (funtype a 0) 

* : (funtype (prodtype number number) number) 

The higher-order nature of the abstract syntax 
makes this straightforward specification possible. 
Note that this specification does not treat let in the 
way ML does, that is, it does not copy the type vari¬ 
ables in instances of a. 


4.2 Attribute Grammar Evaluator 

Most attribute grammars on a language with binding 
constructs will have to pass around an environment 
as context in which the attribute value will be com¬ 
puted. Typically that environment is enlarged when 
descending through a binding construct of language. 
As mentioned above, determining where variables are 
bound often requires a significant amount of work, 
like collecting free variables from a term. 

Using higher-order abstract syntax the repeated 
work can be avoided, thereby improving the efficiency 
of attribute analysis. Moreover, expression of at¬ 
tribute equations is more concise, since the environ¬ 
ment of bound variables can effectively be hidden 
from the user in most cases. 

The Analysis Facility in the Ergo Support System 
can currently process only attribute grammars that 
traverse first-order abstract syntax. The implemen¬ 
tation of an extension of attribute grammars to take 
advantage of the higher-order abstract syntax is out¬ 
lined here and planned for the near future. 

Again, lacking space, the example is not fully ex¬ 
plained but should indicate the form of such gen¬ 
eralized attribute grammars. We show a fragment 
of an attribute grammar that evaluates expressions 
from our simple language. A higher-order subterm is 
treated as if it returns a function from the attribute 
value for the bound variable to the attribute value 
for the whole expression. That function can then be 
applied in the definition of other attributes. In the 
implementation, the function objects are never built, 
but they serve as a convenient, conceptual device. In 
effect, the attribute grammar will be translated into 


another computing the same value, but using envi¬ 
ronments in which the variable name is bound to the 
value to which the function would eventually be ap¬ 
plied. 

E(tvalue) = C(tvalue) | ... 

| let([E^E](tvaluefn), Upvalue 0 )) 
where value = valuefn(value 0 ) 

I apply(E(tvalue°), Upvalue 1 )) 
where value = value 0 (value 1 ) 

| lam([E —> E](j~valuefn)) 
where value = valuefn 

In this example, the evaluation of a let would be 
significantly more efficient that evaluation of and ap¬ 
plication of an abstraction to an argument. The rea¬ 
son is that the term corresponding to the lam expres¬ 
sion is actually built first, then later reduced by appli¬ 
cation, while the reference to valuefn in the clause for 
let will be compiled into a form using environments. 

4.3 Denotational Specification of Language 
Semantics 

We have found that using higher-order abstract syn¬ 
tax significantly simplifies denotational semantics 
specifications. The key idea here, proposed in [11], is 
to specify the semantics of a language simply by giv¬ 
ing an interpretation of the constants, and adopting 
the standard interpretations for variables, abstrac¬ 
tions and applications. 

Semantic specifications are syntax-directed, that is, 
the meaning of a compound expression should be a 
“function” of the meanings of its components in the 
abstract syntax. The constant interpretations are 
exactly these functions, and putting together terms 
with application has the semantic effect of applying 
the meaning of the constant to the meanings of the 
components. This frees the language specifier from 
this step and makes the semantic specifications very 
direct. 

The standard technique for handling binding con¬ 
structs is to make the meaning of an expression be a 
function from environments to values. For example, 
the semantics of a let expression in a call-by-name 
language is commonly given as 

£ [let v = e 0 in ei]p = £ [ei](p [e 0 ]]) 

Using the formulation of let given above, this sim¬ 
plifies greatly to 







5.3 Nondeterminism 


/4 let l = A/ . Xa . f a 

The formulation of the call-by-value case is only 
slightly more complicated. 

Formal syntactic systems involving semantic prop¬ 
erties (such as total or partial equivalence of mean¬ 
ings) that are based on higher-order abstract syntax 
will naturally be much simpler than their traditional 
counterparts. This is because there is less distance 
between the (abstract) syntax being manipulated and 
the meanings that motivate them. 


5 Some Implementation Issues and 
Further Work 

5.1 Implementation of Higher-Order Ab¬ 
stract Syntax 

It seems that the most costly operations on abstract 
syntax are higher-order matching and unification. We 
therefore decided to implement the typed A-terms, 
and provide the first-order interface through explicit 
conversion functions that are called when the first- 
order components of a term are accessed. Our posi¬ 
tive experience with the current implementation con¬ 
firms that this was the right decision. The first-order 
constituents of a A-term are cached as they are com¬ 
puted, thus making term-traversal almost as efficient 
as for first-order abstract syntax. We have not no¬ 
ticed a performance loss during formatted unpars¬ 
ing, which is the most time-consuming operation car¬ 
ried out using the first-order view of abstract syn¬ 
tax. However, the representation of A-terms them¬ 
selves leaves room for improvement. Currently, we 
use the normal form described by Huet in [10], but 
lazy normalization and the use of deBruijn’s nota¬ 
tion [5] should lead to some efficiency improvements 
in the implementation of the unification algorithm. 


5.2 Specification of Name Binding Con¬ 
structs 

Currently the language implementor has to supply 
some highly stylized Lisp functions that achieve the 
translations between higher- and first-order view of 
abstract syntax. We have not yet had enough experi¬ 
ence to feel confident in a design of a user-oriented 
way of specifying the binding properties of a lan¬ 
guage. 


In general during program transformation, many of 
the rules will be too non-deterministic to be simply 
matched against a given program. In such a case we 
need a more specific instance of a general rule. This 
more specific instance can be obtained through sub¬ 
stitution for some of the free variables in the pattern. 
The correctness of the specialized rule follows directly 
from the correctness of the general rule. 

If one uses higher-order matching as part of the 
execution of a higher-order logic program [15] then 
it is the programmer’s responsibility to formulate 
and order the clauses in such a way that the non¬ 
determinism of the higher-order unification is con¬ 
trolled. This requires some experience with AProlog, 
but is in general not too difficult. 

Another solution we have used successfully is to in¬ 
teractively point at subterms displayed in a window, 
for example, to identify subterms over which to ab¬ 
stract. 


5.4 Language Representation 

When one is faced with the task of implementing an 
object language using higher-order abstract syntax, 
one is faced with a variety of choices. The most 
straightforward representation is described in this pa¬ 
per: syntactic categories (usually a subset of the non¬ 
terminals) become types and there is a distinct, pos¬ 
sibly higher-order constant for each operator in the 
language. 

However, sometimes one would like to eliminate 
some of the syntactic sugar from the concrete syntax 
and thus map different concrete syntax expressions 
to the same representation. This is currently possible 
in our implementation, but not very well supported, 
since the unparser would only unparse into concrete 
syntax corresponding to the core language. The ad¬ 
vantage of using a smaller core language is that one 
needs to define semantics, transformation rules, etc., 
only for the core language. 

Another possibility for a more concise representa¬ 
tion of a typed language is to use the types of the 
A-calculus to represent the types of the object lan¬ 
guage. The class of languages for which this is possi¬ 
ble is limited by the expressiveness of the type system 
of the higher-order abstract syntax. 



6 Related Work 

LF, the Edinburgh Logical Framework [1,9,7] makes 
explicit use of a different version of the A-calculus 
to represent logical formulas and programs and the 
deduction system for reasoning about them. The 
way quantifiers are encoded is similar to the way 
it is done in higher-order abstract syntax and goes 
back to Church [4]. Because of the power of their 
A-calculus with dependent function types, it is not 
known whether there is a natural unification algo¬ 
rithm that could be used for proof search in their 
system in a general way. However, their system is 
at the same time weaker in a different respect, since 
it does not allow products or polymorphism. This 
means that many natural formulations of transfor¬ 
mation or inference rules cannot be represented in 
LF. 

Isabelle [18] uses a representation similar to ours 
for the statement of rules, and uses higher-order uni¬ 
fication for deduction. Isabelle’s A-calculus represen¬ 
tation does not have the expressive power of higher- 
order abstract syntax, but explicitly encodes quanti¬ 
fier dependencies. 

AProlog [14,12,17] provides a natural metalan¬ 
guage for writing programs acting on higher-order ab¬ 
stract syntax. This was the basic point made in [15]. 
We plan a generalization of AProlog that would deal 
with products and thus allow us to use it as a very 
expressive metalanguage for metaprogramming in the 
context of language-generic program derivation and 
theorem proving. 
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